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ASSET MANAGERS FREQUENTLY 
LOOK TO PLACE TRADES FOR 
EXECUTION ON BEHALF OF CLIENTS 
IN THE WHOLESALE FX MARKET. 

A VARIETY OF METHODS OF 
TRADING MAY BE USED - THIS 
PAPER WILL FOCUS SPECIFICALLY 
ON THE REQUEST-FOR-QUOTE 
MODEL', WHEREBY AN ASSET 
MANAGER WILL SOLICIT A QUOTE 
FROM A NUMBER OF EXECUTION 
PROVIDERS ON A GIVEN TRADE. THE 
ASSET MANAGER WILL THEN LOOK 
TO TRADE ON THE QUOTE IT DEEMS 


TO OFFER THE BEST OUTCOME. 





Whether the trade is in spot FX, an FX derivative 

or any other FX product, asset managers will be 
seeking to act in their clients’ best interests, both as 
regards the decision to trade and how and where to 
place that trade. This is in keeping with the Global FX 
Code, which envisages that Market Participants will 
handle orders fairly and with transparency. 


If the trade is not executed, this may disadvantage 
the client, or potentially leave the client exposed 
to market risk that it otherwise would not have. 
For that reason, asset managers have a legitimate 
concern to understand why a trade has not 
proceeded. 


In some instances a trade will not proceed because 
it has been rejected by the execution provider.” There 
are two different stages in the trade lifecycle during 
which a rejection may occur — at the quote stage (ie 
where the RFQ itself has been rejected) and at the 
trade stage (ie where a quote has been provided but 
the subsequent attempt to trade has been rejected). 


A key line of communication by brokers, dealers 
and platforms (“execution providers”) to the asset 
manager that placed an RFQ or trade request is 

by provision of a shorthand identifier, called a 
reject code, associated with one or a set of reasons 


1 This covers RFQ quotes either via a single-dealer platform, MTF or API direct technology - in short, any electronic method of FX trading between 
an asset manager and a liquidity provider. It will, by necessity, therefore include reference to RFS where both RFQ and RFS are enabled via any of 
the previously described methods of connectivity. There are a number of other methods of execution, including voice and algo trading. The IA will 
look to explore reject codes for these protocols at a later date. Almost all FX activity likely to be undertaken by an asset manager - including spot, 
outright forward, swaps, mismatched swaps, multi-legged mismatched swaps, and NDFs - is in scope. FX options will not be covered at this time. 
Given the different features of FX options, the IA will explore these separately at a later date. 


? There are a number of possible different outcomes to an RFQ. A trade may also not proceed because the RFQ goes unanswered, or for technical 


reasons is not properly transmitted or received, for example. 


which were the proximate cause of the trade not 
proceeding to a completed transaction. These 
guidelines address such reject codes however 
formatted or transmitted. 


At present, the FX market has no standardised set 
of reject codes. Some execution providers provide 
several dozen, others many fewer. The demarcation 
and extent of each reject code is idiosyncratic 

for each execution provider. It is in the interests 

of clients of asset managers that the reasons for 
rejection are rapidly analysed so that steps can 

be taken to remedy any operational or procedural 
errors, or issues raised with the execution provider. 
These idiosyncratic distinctions do not assist the 
asset managers as much as they might. 


This suggests a standardised messaging protocol 
with a defined set of reject codes could assist 
asset managers and thereby their clients. But it is 
recognised as well that some execution providers 
may wish to distinguish their level of service by 
providing many granular and tailored reject codes. 
The Investment Association does not wish to 
restrict such service distinction nor the right of 
parties to decide the specificities of their business 
relationships. 
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Accordingly, we propose a number of high-level 
reject code categories which would be consistently 
used across all execution providers so as to allow 
key issues and comparisons to be made and 
wherever practical to be automated. These reject 
codes could be applied quickly and would ideally 
be seen on the GUI at the time of the reject. The 
proposed reject codes are intended to ensure that 
the proximate reasons for a quote or trade being 
rejected would be reported under one of the high- 
level categories. 


Taking account of the two phases of the trade cycle 
during which a reject may occur (quote and trade), 
some of the proposed standardised reject codes 
may only apply to rejections that occur during one 
or the other phase. Other reject codes may apply to 
rejections that occur during both phases. Should 

a dealer manually intervene in an auto-trade (for 
example, because the trade was above the auto- 
stream limit) and subsequently reject the trade, 

we would expect one of the proposed reject codes 
to be provided. 





The IA is supportive of the FX Global Code of Conduct. 
In the context of the Global FX Committee’s ongoing 
review of the Code and their goal of improving 
disclosure within FX markets, we would welcome the 
Global FX Committee's support for this work. 


PROPOSED CATEGORIES 


QUOTE REJECTION 


CATEGORY A: 


Credit - quote rejected because of the credit limit 
(be it (i) breached or (ii) not in place) of the client or 
its agent making the request. 


CATEGORY B: 


Pricing outage - where a request-for-quote cannot 
be processed due to pricing being unavailable. 


CATEGORY C: 


Regulatory - where a request-for-quote cannot 
be processed due to regulatory requirements not 
being met. 


CATEGORY D: 


Risk and capital constraints - where a request- 
for-quote cannot be processed as the request 
breaches internal risk constraints such as country 
concentration limits. 


CATEGORY E: 


Static Data - where a request-for-quote cannot 
be processed due to static data errors — for 
example, due to an error in the unique trader ID, 
a counterparty is not properly permissioned, or 
improper product validation. 


CATEGORY F: 


Unsupported Product - where a trade 

cannot be executed because the request covers 
an unsupported product. This may be due to 
unsupported currency pairs for example, or tenor 
restrictions on the client or liquidity provider side. 


CATEGORY G: 


Exceptional - this residual category is provided to 
ensure a complete set of categories exists and there 
should always be a reject code provided. It would 
only be used if a situation not covered by any of the 
first five categories exists. It is not expected that this 
would be used otherwise than on an exceptional and 
very infrequent basis, if at all. 


TRADE REQUEST REJECTION 


CATEGORY A-1: 


Last Look - where a trade request was rejected 
following the use of last look (including cover 
and trade).° 


CATEGORY A-2:’ 


Last Look - Latency - where a trade has been 
Last Looked and where trade execution is prevented 
by latency issues which mean that pricing or 
liquidity is no longer available. 


CATEGORY B: 


Pricing/Liquidity Unavailable - Where a trade 
request has NOT been last looked, and where 
trade execution is prevented because clients are 
attempting to execute on pricing or liquidity that is 
no longer available. 
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CATEGORY C: 


Credit - where a trade request would have been 
executed BUT FOR the credit limit (be it (i) breached 
or (ii) not in place) of the client or its agent making 
the request, the reject code will be given for 

Credit Limit. 


CATEGORY D: 


Static Data - where a trade request cannot be 
executed due to static data errors — for example, 
due to an error in the unique trader ID, a 
counterparty is not properly permissioned, or 
improper product validation. 


CATEGORY E: 


Exceptional - this residual category is provided to 
ensure a complete set of categories exists and there 
should always be a reject code provided. It would 
only be used if a situation not covered by any of the 
first five categories exists. It is not expected that this 
would be used otherwise than on an exceptional and 
very infrequent basis, if at all. 


3 The process by which, following an RFQ, a market participant receiving a trade request imposes an artificial holding window which allows them a 
final opportunity to accept or reject the request against its quoted price. ‘Cover and trade’ is an arrangement where a market participant will look 
to facilitate their client’s trade request without taking on any market risk, and so may decline to execute if an offsetting transaction cannot also 


be executed. 


* Exact Last Look policies will vary from execution provider to execution provider. Various checks may be included within the holding window, 


including price and latency checks. 
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It is recognised that asset managers will commonly However, execution providers should be able 
not deal directly with an execution venue®. All parties even now to map all of their existing reject codes 
participating in an RFQ will need to play a role in unambiguously to one of the categories. If an 
ensuring reject codes are communicated promptly existing reject code contains more than one 
to the asset manager. Platforms will need to be category, it does not appear that this would be clear 
ready to pass on reject codes received from other and useful in any event. The provision of maps 
execution providers. will allow asset managers themselves to make 


temporary coding fixes to assist the analyses and 


The Investment Association will explore the . bey By 
comparisons that their clients’ interests deserve. 


possibility of using agreed digital protocols, such as 


by use of tags under FIX messages. It is recognised We would invite all execution providers to provide 
that for many parties development cycles are such their mapping of their existing reject codes to the 
that automation of this coding system on top of categories to their asset management clients by 

existing reject codes may not be feasible in 2020. the end of Q1 2020. We shall ask members for 


feedback on progress in Q2 2020. 


5 The term is to be read widely, within the EU for example it will include Regulated Markets, Multilateral Trading Facilities, Organised Trading 
Facilities, Systematic Internalisers, Market Makers and Liquidity Providers 
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APPENDIX 1 
ACCEPTANCE TAGS 


There are multiple outcomes to an RFQ, and Manual - The trade request has been accepted, 
even in cases where a trade request is accepted following manual intervention and pricing by a 
there may be aspects of that trade that execution human trader. This may be because, for example, 
providers may wish to flag to their clients. As a the requested trade is above the auto-stream limit. 
future workstream, the industry should explore Ideally this information would be provided in 

the development of acceptance tags, which could real-time. However at a minimum execution 

be applied to accepted trades to Indicate certain providers could look to provide this information 
events. Together with the suggested reject coders ona monthly basis.’ 


this should ensure there is a standard tag applied by 
vendors & platforms, covering all likely eventualities. 
Such tags could include: 


Sub-optimal Trading Conditions - The time 
taken between transmission of order between when 
the dealer is able to execute on a trade request 
Accepted - The trade request has been accepted, may result in situations where, even if the trade is 
with no further comments necessary.® completed, the market may have moved against 
clients in the meantime, resulting in sub-optimal 


Last Look - In order to help clients understand the Pat 
conditions for execution. 


impact Last Look may have on their trades, even 
where that trade has ultimately been accepted, Last 
Looked trades should be tagged. 


5 Included here for completeness. It is already standard procedure for a confirmation message to be sent by execution providers and platforms on 
acceptance. 

7 It is important that asset managers have sight of when and how often manual intervention occurs, both so they can understand any delays in the 
RFQ process as well as analyse how often manual intervention is required when trading with a given execution provider. 
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